Netware Super Library/Netware Super Library.iso/app_note/an009c/an009c.txt

Text File | 1991-01-11 | 85.2 KB | 1,643 lines

NetWare Communications Processes

 Paul Turner
 Consultant
 Systems Engineering Division

Abstract:

This AppNote provides a comprehensive explanation of the protocols and
algorithms that govern communications in the 286-based NetWare, NetWare
386, and Portable NetWare environments. Topics covered include routing
and connection control.

Disclaimer

Novell, Inc. makes no representations or warranties with respect to the
contents or use of these Application Notes (AppNotes) or any of the
third-party products discussed in the AppNotes. Novell reserves the right
to revise these AppNotes and to make changes in their contents at any
time, without obligation to notify any person or entity of such revisions
or changes. These AppNotes do not constitute an endorsement of the third-
party product or products that were tested. The configuration or
configurations tested or described may or may not be the only available
solution. Any test is not a determination of product quality or
correctness, nor does it ensure compliance with any federal, state or
local requirements. Novell does not warranty products except as stated in
applicable Novell product warranties or license agreements.

Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved.

As a means of promoting NetWare AppNotes, Novell grants you without
charge the right to reproduce, distribute and use copies of the AppNotes
provided you do not receive any payment, commercial benefit or other
consideration for the reproduction or distribution, or change any
copyright notices appearing on or in the document.

Introduction

This AppNote is a preliminary excerpt from an upcoming Novell Systems
Engineering Division research report entitled "NetWare Internals and
Structure." It provides a technical description of the protocols that
make client-server communications possible on NetWare networks. The
information contained in this document will be most valuable to those
individuals designing, implementing or administrating large NetWare
internetworks. It will also be useful to individuals and organizations
developing applications specifically for NetWare.

The document begins with an explanation of the packet structures defined
by each protocol. It then describes the algorithms followed by
workstations, routers and file servers when transmitting or receiving
packets.

Protocols

Most computer networks require that information transferred between two
nodes be broken up into blocks, called packets. This packetizing makes
the information more manageable for the sending and receiving nodes, and
any intermediate nodes (bridges or routers). In addition to the
information, or data, that is being transferred, each packet contains
control information used for error checking, addressing, and other
purposes. The protocols being used on the network define the content of
this control information. In most cases multiple protocols exist within a
packet; each protocol defines a different portion of the control
information for the packet and the control information for each protocol
serves a different purpose. When multiple protocols are used, the control
information for the highest level protocol is first placed around the
data, then the control information for each subsequent protocol in the
protocol stack is added to the beginning and/or end of the packet. This
is called envoloping. (See Fig. 1.)

The enveloping pattern illustrated in Fig. 1 is common in the computer
communications industry but the tasks assigned to each protocol in the
packet differs for different vendor's implementations. In an effort to
standardize the definition of protocols-and therefore make the networking
implementations of different vendors interoperable-several standards
organizations have been formed by governments and corporations. One of
these, the International Standards Organization (ISO), has developed a
model, called the Open Systems Interconnection (OSI) model, that
specifies how protocols should be defined in the future. The OSI model
separates the functions required for effective computer communications
(such as error checking and addressing) into seven catagories, or layers.
These layers are the Application, Presentation, Session, Transport,
Network, Data-Link and Physical layers.

: Example of Multiple Protocols in a Packet

 Having been defined prior to the finalization of the OSI model, the
protocols used by NetWare do not all correspond exactly to the OSI
model's definitions. NetWare uses a variety of protocols. Some of these
protocols were developed specifically for NetWare; some are used
throughout the networking industry. The protocols required for
communications between NetWare workstations and file servers are the
following:

o    Medium-access Protocols

o    Internetwork Packet Exchange (IPX)

o    Routing Information Protocol (RIP)

o    Service Advertising Protocol (SAP)

o    NetWare Core Protocol (NCP)

Fig. 2 provides a relative mapping of the NetWare protocols-also called
the NetWare protocol stack-to the OSI model; in actuality, a direct
correlation to the layer boundaries of the two architectures does not
exist. The NetWare protocols follow the enveloping pattern shown in Fig.
1. More specifically, the upper level protocols (NCP, SAP, and RIP) are
enveloped by the IPX and IPX is subsequently enveloped by the medium-
access protocol header and trailer.

: Mapping of NetWare Protocols to OSI Model

Medium-Access Protocol Implementations

A number of medium-access protocols have been defined, many of which are
used with NetWare. The focus within this document is on the
implementations of medium-access protocols, the most common of which are
802.5 Token-Ring, 802.3 Ethernet, Ethernet v2.0, and Arcnet. The 802.x
protocols have been defined by the Institute of Electrical and Electronic
Engineers (IEEE). Ethernet v2.0 was co-developed by Xerox and Digital
Equipment Corporation, and Arcnet was developed by Datapoint, Inc. These
medium-access protocol implementations are primarily concerned with the
transport of packets from one node to another on a single network
segment.

Medium-access protocols provide bit-level error checking in the form of a
cyclic redundancy check (CRC). This CRC, which is appended to every
packet that is transmitted, assures that 99.9999 percent of the packets
successfully received will be free of corruption. In view of this level
of integrity, NetWare does not provide any additional bit-level error
checking within any of its upper-level protocols. (Note that bit-level
error checking checks to make sure that bits within a packet have not
been corrupted. The packet-level error checking discussed later checks
that complete packets are not lost.)

Medium-access protocol implementations define the addressing that
distinguishes each node on a NetWare network. This addressing is
implemented within the hardware of each network interface card (NIC). To
move a packet to the proper node on a network, a medium-access control
(MAC) header is placed at the beginning of every packet. This header
contains source and destination node address fields to indicate where the
packet originated and where it is going. Each NIC checks the destination
address in the MAC header of each packet sent on the network segment is
is attached to. If the destination address matches the NIC's own address,
or if the packet is a broadcast packet intended for all nodes, the NIC
will copy the packet.

Bit-level error checking and node addressing are provided by the majority
of medium-access protocol implementations. IBM's Token-Ring (802.5)
implementation defines a method of routing called source routing. Source
routing allows ring segments to be interconnected by bridges, allowing
administrators to segment network traffic. This requires that each
workstation maintain a table of routes to the nodes it is communicating
with. Furthermore, routing information must be included in the MAC header
of each packet it sends. This information instructs bridges how to
properly forward each packet to its destination. Source routing can be
used instead of or in conjunction with NetWare routing.

Internetwork Packet Exchange (IPX)

The IPX protocol was adopted by Novell from Xerox Network System's (XNS)
Internet Datagram Protocol. IPX is a datagram, connectionless protocol
that does not require an acknowledgment for each packet sent. This packet
acknowledgment, or connection control, must be provided by protocols
above IPX. IPX defines internetwork and intranode addressing schemes,
while relying on the network hardware for the definition of node
addressing.

The network number assigned in NETGEN (NetWare 2.1x) is the basis of
IPX's internetwork addressing. Each network segment on a NetWare
internetwork must be assigned a unique network number. This network
number is used by routers to forward packets to their final destination
segment.

The IPX intranode address comes in the form of socket numbers. Since
several processes are normally operating within a node, socket numbers
provide a sort of mail slot so that each process can distinguish itself
to IPX. As a process needs to communicate on the network, it requests
that a socket number be assigned to it. Any packets that IPX receives
that are addressed to that socket are passed on to the process. Hence,
socket numbers provide a quick method of routing packets within a node.

Novell has reserved several socket numbers for specific purposes. These
are shown in Fig. 3. Since socket numbers are internal to each node,
several workstations can use the same socket number at one time without
any fear of confusion. All NCP requests from workstations must be
addressed to socket 451h.

: Socket Numbers Used in The NetWare Environment

The network, node, and socket addresses for the both the destination and
the source are held within the packet's IPX header. The IPX header is
placed after the MAC header and before the packet data. (Packet data is
usually the header of a higher-level protocol.)  Fig. 4 illustrates the
structure of an IPX packet on an 802.3 network.

: Structure of an IPX Packet

Routing Information Protocol

The Routing Information Protocol (RIP) facilitates the exchange of
routing information on a NetWare internetwork. Like IPX, the RIP was
derived from XNS. However, an extra field was added to the packet
structure to improve the decision criteria for selecting the fastest
route to a destination. This change prohibits the straight integration of
NetWare's RIP with other undeviating XNS implementations.

The single packet structure defined by the RIP allows the following
exchanges of information:

o    Workstations locate the fastest route to a network number by
     broadcasting a route request (represented by "Route Request" entry
     on the TRACK ON screen).

o    Routers request routing information from other routers to update
     their own internal tables by broadcasting a route request
     (represented by "Route Request" entry on the TRACK ON screen).

o    Routers respond to route requests from workstations and other
     routers.

o    Routers perform periodic broadcasts to make sure that all other
     routers are aware of the internetwork configuration.

o    Routers perform broadcasts whenever they detect a change in the
     internetwork configuration.

The RIP packet structure is shown in Fig. 5. This structure is enveloped
within the data area of IPX. The Operation field indicates whether the
packet is a request or a response. A 1 in this field indicates a request
and a 2 indicates a response. The Operation field can be followed by one
or more (n) sets of information, each consisting of a network number and
the number of Hops and Ticks to that network number. A RIP packet can
contain a maximum of 50 sets of network number information.

The term "Hops" refers to the number of routers that must be passed
through to reach a network number. A "tick" is roughly 1/18 of a second
(there are 18.21 Ticks in a second, to be precise). The number of Ticks
measures how much time the packet takes to reach a network number. The
number in this field is always at least one. The original XNS definition
of the RIP did not include the Number of Ticks field. The Ticks field was
added by the developers of NetWare so that the NetWare shell could
estimate how long it should wait for a response from a file server. (This
will be explained in the discussion of the shell's receive time-out.)
Also, if multiple routes exist to a network number, a router uses the
route with the shortest number of Ticks when forwarding packets to that
network number.

If a RIP packet is a request for information, only the Network Number
field applies; the Hops and Ticks fields are essentially nulled out. A
response packet can be either a reply to a request from a router or
workstation or a periodic broadcast by a router.

: RIP Packet Structure

Service Advertising Protocol (SAP)

The Service Advertising Protocol (SAP) allows service-providing nodes-
such as file servers, print servers, and gateway servers-to advertise
their services and addresses. The SAP makes the process of adding and
removing services on an internetwork dynamic. As servers are booted up,
they advertise their services using the SAP; when they are brought down,
they use the SAP to indicate that their services will no longer be
available.

Through the SAP, clients on the network can determine what services are
available on the network and obtain the internetwork address of the nodes
(servers) where they can access those services. This is an important
function, since a workstation cannot initiate a session with a file
server without first having that server's address.

A gateway server, for instance, will broadcast a SAP packet every 60
seconds (the period defined for all servers advertising with the SAP)
onto the network segment it is connected to. The SAP agent in each router
on that segment copies the information contained in the SAP packet into
an internal table called the Server Information table. Because the SAP
agent in each router keeps up-to-date information on available servers, a
client wanting to locate the gateway server can access a nearby router
for the correct internetwork address.

Like the RIP, the SAP uses IPX and the medium-access protocol for its
transport.  Fig. 6 illustrates the SAP packet structure. The first field
defines the operation that the packet is performing. The packet can
perform five different operations:

o    A workstation request for the name and address of the nearest server
     of a certain type (this is represented by a "Get Nearest Server"
     entry on a TRACK ON screen.)

o    A general request, by a router, for the names and addresses of
     either all the servers or all the servers of a certain type on the
     internetwork ("Send All Server Info." on TRACK ON.)

o    A response to either a "Get Nearest Server" request ("Give Nearest
     Server" entry on TRACK ON) or a general request

o    Periodic broadcasts by servers and routers

o    Changed server information broadcasts

Following the Operation field are one or more sets of fields. Each set
includes a service type server name, network address, node address,
socket number and a number of Hop fields. If the packet contains
information about more than one server, it will contain more than one set
of fields (n sets of fields). Each SAP packet can contain information
about up to seven servers.

: SAP Packet Structure

NetWare Core Protocol

The NetWare Core Protocol (NCP) makes interaction between clients and
file servers possible by defining two aspects of their interaction,
connection control and service request encoding. Because the creation and
handling of NCP packets is done by the NetWare shell or NetWare Requester
for OS/2, you do not need an in-depth understanding of the NCP,but you
should  have some idea of what the protocol does.

The NCP provides its own session control and packet-level error checking
instead of relying on other protocols for these functions. Consequently,
the modularity of the protocol stack is reduced but, in the long run, a
more efficient mechanism is attained.  Fig. 7 shows the general structure
of an NCP packet. When a client establishes a session with a file server,
it is assigned a connection number. This connection number must be
included in all subsequent service requests that the client submits. The
connection number allows the file server to keep track of which clients
are making requests, for response and security purposes.

:  Structure of an NCP Packet

Each NCP request packet submitted on a given connection must be assigned
a sequence number by the client. The first request following the
establishment of the connection is assigned the number 1; that number is
incremented by one for each subsequent request. When a file server
finishes processing a request, it places the sequence number for that
request in the response packet. Hence, the client can make sure that it
is receiving the correct responses for the requests that it submits.

Each of the services available at a NetWare file server has been assigned
a number. When it needs to submit a request to a server, the shell or
requester places the number-as well as any additional information that
might be needed-in the service code field of the NCP packet. Depending on
the service being requested, the NCP might provide additional fields for
the shell to give specific instructions to the file server-such as which
part of a file to read. The file server might report any problems or
errors that might have occurred while processing the request in these
additional fields.

Packet Delivery

On a NetWare network, the successful delivery of a packet depends on the
proper addressing of the packet and the internetwork configuration
(whether it is a single segment network or series of segments
interconnected by repeaters, bridges and/or routers). The addressing of
the packet is handled in its medium-access protocol and IPX address
fields. To send a packet to another node, the sending node must know the
full internetwork address (network, node, and socket) of the node it
desires to send to (the destination node). (The process of obtaining
another node's address is explained in the section entitled "Establishing
a Connection.") Once the sending node has the destination node's address
it can proceed with addressing the packet. The way the MAC header of that
packet is addressed, however, depends on whether the sending and
destination nodes are separated by a router.

In the event that the sending and destination node are on the same
network segment-that is, they both have the same IPX network address-the
sending node addresses the packet in the following way: The node address
of the destination node is placed in the MAC header destination address
field. The node address of the sending node is placed in the MAC header
source address field. The full internetwork address of the destination
node is placed in the IPX header destination address fields. The full
internetwork address of the sending node is placed in the IPX header
source address fields.

Fig. 8 shows an example of two nodes that are connected to network number
AA. The sending node (node 01) sending a packet to node 02. The sending
node places node address 02 in the destination field and node address 01
in the source field of the MAC. In the destination address fields of the
IPX header, the sending node places AA, 02 and 451 (the full internetwork
address of the receiving node). The sending node places its own
internetwork address of AA, 01 and 4003 in the source address fields of
the IPX header.

: Transmission to Same Network Segment (No Routing Required)

Network Interconnection Devices

The addressing method depicted in Fig. 8 is used when the two nodes
reside on the same physical segment (or ring) or if they reside on
separate segments interconnected by repeaters or bridges. A repeater is a
Physical Layer (OSI model) device that amplifies the signal of one
segment onto one or more other segments. Repeaters are used to extend the
maximum possible distance between end nodes on a segment. They are
completely transparent to the sending and receiving nodes.

A bridge is a Data-Link Layer device used to interconnect cable segments
locally or over wide area network links. Instead of simply amplifying a
signal as repeaters do, bridges retransmit packets received on one
segment onto another segment. Bridges are considered Data-Link Layer
devices because they examine the data-link (or MAC header) portion of
packets before retransmitting them onto other segments. There are two
predominant types of bridges, transparent bridges and source routing
bridges.

Transparent bridges interconnect two or more segments. They examine the
MAC header source and destination fields of every packet transmitted on
their connected segments. From the source address fields of packets,
these bridges develop a table of the nodes that reside on (or are
accessible through) each of their connected segments. With this table of
information, a bridge can determine whether packets should be passed on
to other segments.

Fig. 9 shows a transparent bridge connected to two separate segments.
After examining the packets transmitted on both segments it creates a
table that tracks which nodes exist on each segment. With this table, the
bridge can filter unnecessary traffic. For instance, if node 1 sends a
packet to node 5, the bridge will not retransmit that packet on its port
B. It will, however, retransmit packets sent from node 1 to node 7. Like
repeaters, transparent bridges-as their name implies-are transparent to
the sending and receiving nodes.

: Example Transparent Bridge

Routers

Routers, like bridges, interconnect different network segments; however,
the operation of routers and bridges is quite different. Routers by
definition are network layer devices. (See Fig. 10.) In other words,
routers receive their instructions for forwarding a packet from one
segment to another from a network layer protocol. The network layer
protocol that routers use in the NetWare environment is IPX. NetWare-
compatible routers are available with NetWare or from third-party
manufacturers. The routers that come packaged with NetWare have actually
been misnamed bridges in the past. The NetWare routers include what has
been called the internal bridge within NetWare file servers and external
bridge installed at workstations. Novell has officially renamed these two
devices internal router and external router.

NetWare-compatible routers may be configured to interconnect two or more
segments. Each of these segments, however, must be assigned a unique IPX
network number to distinguish it from other segments on the internetwork.
A segment's network number must be configured into each of the routers
connected to that segment. The network number serves as a common address
for each node connected to a segment.

: OSI Representations of Network Devices

Packet Routing

When a node wants to send information to another node, it must first have
network address-as well as the node address-of the destination node. If
the two nodes have the same network number (reside on the same segment),
the sending node can simply send packets to the destination node using
method illustrated in Fig. 8. On the other hand, if the two nodes have
different network numbers (reside on different network segments), the
sending node must find a router on its own segment that can forward
packets to the destination node's network segment. To find this router,
the workstation broadcasts a RIP packet requesting the fastest route to
the destination node's network number (RIP requests are discussed in more
detail later in the section entitled "Establishing a Connection". This
RIP request is responded to by the router residing on the sending nodes
segment with the shortest path to the desired segment; in the response,
the router includes its node address.

Once the sending node receives the router's node address, it is prepared
to send packets to the destination node. The sending node addresses these
packets in the following way: It places the destination node's
internetwork address (network, node and socket number) in the destination
address fields of the IPX header. Next the sending node places its own
internetwork address in the source address fields of the IPX header. Then
the sending node places the node address of the router-the one that
responded to the RIP request-in the destination address field of the MAC
header. The sending node places its own node address in the source
address field of the MAC header. (See Fig. 11.)

: Packet Addressing Through a Router

 When a router receives a packet to be routed, it can take one of two
possible actions. If the packet is destined for a network number that the
router is directly connected to, the router will place the destination
node address from the IPX header in the destination address field of the
MAC header, place its own node address in the source address field of the
MAC header, and transmit the packet. (See Fig. 11.)

If the router is not directly connected to the segment that the final
destination node resides on, however, it will send the packet to the next
router in the path to the destination node. To forward the packet to
another router, the router will place the node address of that other
router in the destination address field of the MAC header. The router
will place its own node address in the source address field of the MAC
header. The router leaves the IPX header as initially set by the sending
node and sends the packet.

Routing Information Administration

To forward packets by the best possible route, NetWare routers maintain a
Routing Information table that holds information about all the network
segments on the internetwork.  Fig. 12 gives an example of a Routing
Information table (only the fields  pertinent to this discussion have
been included). Each entry in the Routing Information table gives the
router forwarding information for a network segment.

: Portion of Routing Information Table

The first field contains the network numbers for segments that the router
is currently aware exist. The router simply matches the destination
network number in the packet's IPX header with an entry in this field to
get its forwarding instructions for the packet. The second field
indicates the number of routers that must be traversed to reach the
network segment.

An estimate of the time necessary to reach the destination segment is
recorded in the third field. The initial time estimate for a segment is
the responsibility of the driver directly connected to it. This driver
reports this estimate to its router. This time estimate is used by the
router in its periodic broadcasts to indicate the time necessary to
deliver a packet to a node on that segment. The method that drivers use
for estimating the time delay on a segment depends on the segment type.
For local segments with more than 1 Mb/sec of bandwidth (Token-Ring,
Ethernet, Arcnet, and so on), the driver makes the assumption that
delivery time is one tick. For remote segments (T1, 64 kbps, X.25, and
asynchronous), the driver will periodically poll to determine the current
time delay. For instance, the delay for a T1 link normally ranges from
six to seven Ticks. If this delay changes, the driver will inform its
router. As information about the segment is passed along throughout the
network (by way of periodic broadcasts), routers will add any additional
delay that they impose to the initial time estimate for the segment.

The NIC field of the Routing Information table records which NIC in the
router the network segment can be reached through. The Immediate Address
field contains the node address of the router that can forward packets to
each segment. If the segment is directly connected to the router, this
field will remain empty. The "Net Status" field indicates whether the
segment is directly connected to the router and whether the segment is
considered reliable. The final field is used to make sure that
information about the segment is current.

For NetWare versions prior to 2.15c, the Routing Information table keeps
a list of all alternate routes for each network number in case the
primary shortest route to a network number goes down. In other words, if
the router can reach the segment through more than one of its NICs, it
will make a record of both routes. The fastest route, the one that
requires the least number of Ticks, will always be used as the primary
route. NetWare versions after 2.15c maintain alternate routes only if
these alternate routes require the same amount of Ticks to reach the
segment as the primary route. This reduces the size of the Routing
Information table.

Routing Information Broadcasts

On an internetwork, routers are constantly exchanging information with
each other to make sure that their Routing Information tables reflect up-
to-the-minute changes in the layout of the internetwork. To accomplish
this, routers transmit a series of broadcasts from the time they come up
until they are brought down. These broadcasts can be separated by the
time at which they occur:

o    Initial broadcast of directly connected network segments

o    Initial request to receive routing information from other routers

o    Periodic broadcasts (every 60 seconds) of current list of active
     network numbers

o    Broadcast of change in internetwork configuration

o    Final broadcast when brought down

Although the broadcasts occur at different times and, for the most part,
contain different information, they must follow two important rules.
First, each broadcast must be a local broadcast, addressed so that it
will not be immediately passed on, intact, by the routers that receive
it. This reduces the network traffic created by these information
exchanges. Second, routers must follow a "best information" algorithm
when providing information to other routers through a broadcast (since
the second broadcast listed above is a request for information, this rule
does not apply to it).

Best Information Algorithm

The purpose of routing information broadcasts is twofold: to allow a
router to share its current impression of the layout of internetwork with
other routers, and to inform the routers of an internetwork change so the
routers can update their tables. A router sends routing information
broadcasts to every network segment that it is directly connected to. The
first rule of the best information algorithm dictates that a router about
to broadcast to a particular network segment should not include any
information about other segments that it has received from the segment to
which the information is being sent.

For example, if the router within server FS2 in Fig. 13 is going to
broadcast a routing information broadcast to network segment BB, it will
not include information that it received from FS1 about network segment
AA. If it did, someone on segment BB might erroneously conclude that
there are two paths to segment AA-one through FS1 and another through
FS2.

: The Best Information Algorithm

The best information algorithm also states that routers should not
include information about the network segment that they are sending
routing information broadcasts to. For example, FS2 would not include
information about BB in its broadcast onto BB.

Taking these rules into account, the information that FS2 would broadcast
onto segment BB would be information about segments CC and DD.

Initial and Periodic Broadcasts

When a router is first brought up, it places the network numbers of its
directly connected segments into its Routing Information table. Then,
following the best information algorithm, the router sends a routing
information broadcast to inform the routers on its directly connected
segments of the segments that the router will be making available. The
router next broadcasts a request to each of its directly connected
segments for information about all other network segments that exist on
the internetwork. This request is responded to by all the routers (each
using the best information algorithm) on these directly connected
segments. The router places the information gleaned from these responses
in its Routing Information table. Fig. 14 illustrates this initial
sequence of broadcasts.

: Sequence Used to Build and Maintain Routing Information Table

Once the router has performed these initial broadcasts and updated its
Routing Information table, it is ready to accept routing requests and
route packets. In addition to routing packets, the routers will broadcast
all the information in their Routing Information table (except that
excluded by the best information algorithm) to each of their connected
network segments every 60 seconds. Routers perform these periodic
broadcasts to make sure that all routers on the internetwork remain
synchronized.

Because of lower bandwidth of X.25 and asynchronous links, routers do not
perform 60 second broadcasts on these links-only initial broadcasts,
changed information broadcasts and final broadcasts are sent over these
links.

Changed Information Broadcasts

When a router receives information that causes it to change its Routing
Information table, the router will immediately pass that information on
to its other directly connected network segments except the segment that
the router received the information from. If a new network segment comes
up or an existing segment goes down, all the routers on the internetwork
will learn about the change in a short amount of time.

The primary cause of a change in the internetwork's configuration are
file servers and external routers coming up or going down. If a router
needs to be brought down (using the DOWN command at the console) the
router will inform its directly connected segments of the fact before
discontinuing service. The router issues broadcasts (as always, using the
best information algorithm) that indicate that the network segments which
the router had made available will no longer be accessible through this
router. (See Fig. 15.)

: Routers Inform Other Routers When Going Down

The Process of Aging

If a router goes down due to a hardware failure, power glitch, or power
outage, other routers will not be notified that a change has occurred. To
safeguard against this eventuality an "aging" mechanism has been built in
to NetWare routers.

Routers maintain a timer for each entry in their Routing Information
table. Every time that information is received concerning the entry, the
timer is reset to zero. If the timer reaches three minutes, the router
assumes that the route to the network number is down and broadcasts that
fact to its other segments. Since this information is new or changed, the
routers that receive the information will pass it on immediately and the
change will quickly permeate the internetwork.

Service Advertising

Using the SAP, servers on a NetWare network can advertise their services
and addresses. The information that these servers broadcast is not
directly used by clients but instead collected by a SAP agent within each
NetWare router on the server's segment. The SAP agents store this
information in a Server Information table and, if they reside within a
server, in their server's bindery. The clients can then contact the
nearest SAP agent or file server for server information.

The SAP broadcasts that servers perform are local broadcasts and,
therefore, only received by SAP agents on their connected segments.
Consequently, SAP agents periodically broadcast their server information
so that all SAP agents on the internetwork have information about all
servers that are active on the internetwork-this is the same broadcast
method used by routers to distribute and exchange network number (RIP)
information.

Server Information Table

The table that SAP agents use to store information received in SAP
broadcasts is called the Server Information table. If all SAP agents on
the internetwork are exchanging SAP information properly, each agent's
Server Information table should have information about all the servers on
the internetwork-thus providing clients with nearby access to the
addresses of all the servers on the internetwork. Fig. 16 illustrates
some of the more pertinent fields of the Server Information table.

: Portion of a NetWare Router's Server Information Table

The Server Address field contains the service's full address, including
network, node, and socket addresses. The Server Type field holds a number
designating what type of service the server provides. One server might
provide printing services as opposed to file services, for instance. The
server type designation used to assign numbers to the different services
that servers provide is part of a more generic scheme used in the bindery
to classify objects. Some of the more common object types are shown in
Fig. 17.

: Object Types

The Time Since Changed field is used for aging servers that have
unexpectedly gone down. The NIC that the information about the server was
received on is specified in the NIC Number field.

The way that information within the Server Information table is stored
makes sequential access (send me information about all servers with
server type 4, for instance) possible but makes database access (send me
information about server NCS) very difficult. Therefore, the Server Name,
Server Address, Server Type and Hops to Server fields of the Server
Information table are periodically copied to file server's binderies by
internal SAP agents-SAP agents that reside within file servers. With this
information stored in file server binderies, any client that has a
connection with a NetWare file server can query the bindery for the
address of a specific server.

Server Information Administration

When a file server is first brought up, its internal SAP agent places the
name of the server in the agent's Server Information table. The SAP agent
then sends a SAP broadcasts onto each of its directly connected segments
to inform the SAP agents on those segments that a new server has become
available. (See Fig. 18.)

: Sequence Used to Build and Maintain Server Information Table

After performing its initial broadcasts, the SAP agent broadcasts a
request onto each of its directly connected segments for information
about other servers that exist on the internetwork. These requests are
responded to by all the SAP agents on these directly connected segments.
The SAP agent places the information received in these responses in its
Server Information table. Thereafter, the SAP agent performs broadcasts
about the servers that it is aware of every 60 seconds (except on
asynchronous and X.25 links). illustrates these initial and periodic
broadcasts.

As with routing information broadcasts, all server information broadcasts
are local broadcasts and are subject to the best information algorithm.
Any changes in server information are passed on immediately to ensure
current information across the internetwork. The router applies the aging
process to its Server Information table entries in case any servers
become unavailable. Finally, if the router is brought down, it will
indicate to its directly connected segments that the servers the router
has been advertising will no longer be available. (See Fig. 19.)

: FS2 Brought Down

File Server Addressing

Value-added servers, such as gateway and print servers, normally contain
only one network adapter and will use the address of that adapter as the
address they advertise in their periodic SAP broadcasts. NetWare file
servers, on the other hand, may contain multiple adapters. This requires
that they use some sort of convention for advertising the address of
their file services; the convention used for this addressing differs for
286- and 386-based servers. Within the 286-based environment, the file
services of a server are addressed with respect to its NIC A. This
convention guarantees consistency since every server will have at least
one network adapter installed. (See Fig. 20.) If you enter an SLIST
command, the address you see for 286-based servers is the network and
node address assigned to the server's NIC A.

: Addressing of File Services on a 286-based NetWare File Server

In the NetWare 386-based servers, an internal network has been added for
the addressing of internal services, as shown in Fig. 21. This different
method of addressing requires that an internal network number be assigned
when a NetWare 386-based file server is brought up.

: Addressing of File Services in NetWare 386-based Server

Fig. 22 displays an SLIST screen that contains 286- and 386-based
servers. The 386-based servers can be distinguished by their node address
of one. This node address is assigned to the file services on the
internal network number. The implementation of redundant cabling systems
with 286-based servers is discussed in a later section.

: Example SLIST Listing

Client-Server Interaction

The NetWare shell facilitates client-server communications for DOS-based
workstations. In a typical client-server interaction, one station (the
client) requests services from another station (the server). Through the
shell, DOS-based applications can request file services (such as writing
to and reading from files) from NetWare file servers. At the workstation,
the shell, the user application, and the user together act as the client
requesting file services; the NetWare file server acts as the server
providing file services.

The shell, then, is the liaison between the client (the user application)
and the server. The shell performs the tasks necessary to request file
services from a NetWare file server: for example, establishing a
connection with the file server, maintaining the connection, and
terminating the connection.

The NetWare shell is a terminate-and-stay-resident (TSR) program called
NETx.COM (where x depends on the version of DOS being run). NETx.COM is
loaded into a NetWare workstation's memory when the workstation is
booted. Before you load the shell, however, you must load another TSR
called IPX.COM

IPX.COM

Novell's IPX protocol serves as the communications link with the NIC
installed in the workstation. At installation, a customized version of
IPX.COM is generated for each workstation by linking in a driver written
specifically for the NIC that resides in that workstation. Once IPX.COM
is loaded, any workstation programs, including the shell, can communicate
on the network through NetWare's IPX protocol.

In addition to interfacing with the NIC, IPX.COM performs several
communication-related functions. For example, it manages the IPX sockets
used with the workstation. The shell and other applications access
IPX.COM to open and close IPX sockets. When the workstation receives an
IPX packet, IPX.COM checks which socket the packet is addressed to and
passes the packet to the program having that socket open.

Finally, IPX.COM is responsible for determining the address of the
network segment to which the workstation is physically connected. The
workstation's network number, along with its node address, make up the
workstation's full internetwork address.

IPX can determine the workstation's network number in one of two ways. In
the first method, IPX.COM watches for any RIP broadcasts sent on the
network. Since RIP packets are not forwarded to other network segments,
IPX knows that this type of broadcast originated on the segment to which
the workstation is directly connected. IPX simply reads the source
network address contained in the IPX header of a RIP broadcast to
determine the workstation's network number.

IPX uses an alternate method if the shell requests a route to a network
number before IPX can determine the workstation's network number from a
RIP broadcast. In this case, IPX broadcasts a Get Local Target request,
which requests the fastest route to the destination network number
requested by the shell. Upon receiving a response, IPX.COM checks the
source network number in the IPX header of the response packet. This
source network number (the network number of the router that responded to
the Get Local Target request) is the workstation's network number.

The NetWare Shell

The shell (NETx.COM) acts as the interface between user applications and
NetWare file servers. As user applications make requests, the shell
determines whether the requests should be handled locally by DOS or sent
to a server on the network. If the shell determines that the request
should be sent to a network server, the shell formulates a request
packet, hands it to IPX.COM for transmission, and waits for a response.

Prior to submitting any requests to a server, the shell must establish a
connection with that server. The shell can establish a connection to a
server in two ways: When the shell is first loaded at the workstation, it
logically attaches to the first server that responds (usually the server
nearest to the workstation). The LOGIN and ATTACH command line utilities,
when executed, also establish a server connection.

To establish a connection, the workstation and the server must exchange
several packets: a packet requesting that a connection number be assigned
to the shell, and another proposing the maximum packet size that will be
allowed in the interaction between the file server and the shell. Before
sending these initial packets, the shell needs the address of the server
and a route to the server.

Getting a Server's Address

To get a server's address, the shell can use the SAP to broadcast a
request for the address of the nearest server-a Get Nearest Server
request. All routers on the workstation's network segment having
information about the nearest server respond to the Get Nearest Server
request. Each response contains the nearest server's name, its full
internetwork address, and the number of Hops required to reach the
server. (See Fig. 23.)

: Getting the Address of the Nearest File Server

 When first loaded at a workstation, the shell issues a Get Nearest
Server request to establish an initial connection to a file server. If
the shell loses its connections with all file servers, it resorts to the
Get Nearest Server request method to re-establish a server connection.

A second method the shell uses to get a server's address is to use the
NCP to access a file server's bindery. The bindery is a database within
NetWare file servers that contains information about many network
entities, including users, groups, and servers.

Because the shell must already have a server connection before it can
access the server's bindery, the shell can use this second method only
after it has established an initial connection to a file server. The
LOGIN and ATTACH utilities use this method, as does the new "preferred
server" shell (version 3.01). These utilities allow the user to specify a
specific file server name, and then these utilities use that name to scan
the bindery for the server's address.

Getting a Route to a Server

Once the shell has the address of a server, it needs a route to that
address. The shell uses this route for all subsequent communications with
the server for the duration of the connection.

To obtain a route, the shell submits a Get Local Target request to
IPX.COM. IPX first compares the network number of the desired server to
the workstation's network number. If these two numbers are the same, IPX
tells the shell to send requests directly to the server (without going
through an intermediate router).

If the network number the shell submits and the workstation's network
number are not the same, IPX broadcasts a RIP request for the fastest
route to the submitted network number. Whichever router on the
workstation's network segment has the shortest route to the network will
respond to the request. More than one router might respond if several
routers have a route equal to the shortest route. IPX accepts only the
first router's response, discarding all others.

IPX then returns to the shell the node address of the first router that
responded. The shell places the node address of this router in the MAC
header of a Create Connection request packet; it addresses the IPX header
of the request packet to the file server it wants to connect to. With the
packet addressed in this fashion, the router will receive the packet
first, check the IPX destination address, and forward the packet toward
the network number on which the file server resides. (See Fig. 24.)

: Requesting the Fastest Route to an Address

Establishing an Initial Connection

To establish its connection to a file server, the shell uses a
combination of the SAP, the RIP, and the NCP. The sequence followed is
slightly different for the new "preferred server" shell (version 3.01)
than it is for previous shell versions.

Fig. 25 shows the steps taken by pre-v3.01 shells to make a connection
with a file server. The first column represents the call or packet sent.
The second column lists the source, or sender, of the packet. The third
column lists the addressee of the packet. The final column indicates the
protocol used for the packet.

: Initial Connection Sequence for NetWare Shells

We have already seen how the first four steps work. In steps 1 and 2, the
shell obtains the address of the nearest server. Step 3 is IPX.COM's
request for the fastest route to the address that the shell received in
step 2. Step 4 is the response by all routers with the shortest route to
that segment.

Steps 5 through 8 show the packets exchanged between the shell and the
server to establish the initial connection. Once this connection is made,
the shell moves to the background (terminates-and-stays-resident) and
returns the DOS prompt to the user. The user can then execute LOGIN.EXE
to log in to the connected server or to another server.

The Preferred Server Shell

The preferred server shell (v3.01 and above) features several additional
functions not offered by older versions of the shell. As its name
implies, the preferred server shell allows users to specify, either at
the command line or in the SHELL.CFG file, which server they would like
to connect with. Whether or not a preferred server is specified, the
preferred server shell goes through the same initial eight steps as the
old shells.

If the server the shell connects to during the initial eight steps is not
the preferred server the user specified, the preferred server shell
performs several additional steps to establish a connection with the
specified server. (See Fig. 26.)

For instance, if the workstation in Fig. 24 initially connects to FS1 and
the user specified FS3 as the preferred server, the shell will follow a
sequence similar to that shown in Fig. 25. As you can see in step 9, the
preferred server shell uses the bindery method of acquiring the server's
address.

: Connection Sequence for the Preferred Server Shell

Steps 11 and 12 of this preferred server sequence are not always
required. If the preferred server resides on the same network segment as
the workstation, the shell skips these two steps and sends the Create
Connection request directly to the server. The shell destroys the
connection with the initial server once it has successfully established
the connection with the preferred server.

Another major difference between old shells and the preferred server
shell involves the receipt of Give Nearest Server responses. Older shells
accept the first Give Nearest Server response they receive and ignore all
subsequent responses. Preferred server shells accept the first response
also, but save the next four Give Nearest Server responses in case a
connection cannot be made to the first server.

Servers respond to Get Nearest Server requests even if they have no free
connections. Consequently, older shells fail to establish a connection
(steps 5 and 6 of Fig. 25) if the first Give Nearest Server response they
receive is from a server with no free connections. The preferred server
shells, on the other hand, can refer to the next saved Give Nearest
Server response if the current attempt to establish a connection fails.

LOGIN.EXE

Users can run LOGIN.EXE at any time after they have established a
connection to a NetWare file server. LOGIN submits the user's name and
password to the file server for verification. It also establishes a new
server connection if the user specifies a file server in the LOGIN
command.

If the server specified at the command line is not the one the shell is
already connected to, LOGIN follows the steps outlined in Fig. 27. Once
these steps are completed, LOGIN verifies the username and password. If
the server specified at the command line is located on the same segment
as the workstation, steps 3 and 4 are not necessary.

: Additional Steps Performed by LOGIN.EXE

 ATTACH.EXE uses the same sequence as that described for LOGIN.EXE when
establishing connections to a file server.

Connection Management

Communication between any two workstations requires a certain amount of
responsibility on both sides to ensure that no information is lost. NICs
maintain error checking at the bit level in the NetWare environment. File
servers and workstation shells  handle packet- and session-level error
checking; each maintains a table to handle this level of error checking.
The NCP governs the way that the connection control information is
exchanged. (It is a common misconception that SPX is used for packet
level error checking between workstations and servers; however, SPX is
only used for peer-to-peer interaction.) Every NCP packet submitted to a
NetWare file server by a client must have a connection number and
sequence number attached to it. The connection number is the number that
client was assigned by the file server when the connection was
established. The sequence number identifies each packet so that both the
server and the shell can determine when a packet is lost.

The Shell's Connection Table

NETx.COM (the shell) can support up to eight server connections
concurrently. NETx.COM maintains a connection table to track these
connections. (See Fig. 28.) Within each entry in this table, the shell
stores the name and full internetwork address of the server it is
connected to. If the shell is forwarding packets through an intermediate
router to the server, the node address of that router will be stored in
the Router's Node Address field. The shell's connection number and packet
sequence number are also in the table. The sequence number is set to zero
when the connection is first established and incremented with each new
request.

: Portion of Shell's Connection Table

The shell's connection table also maintains two time-outs. One time-out
is the maximum time that the shell will wait for a response from the
server before resending a request packet. This time-out is based on an
estimate of the time (in ticks) needed to deliver a packet to the server.
This time estimate is provided by the router in its Give Immediate
Address response. (If the workstation and the server are on the same
segment, this value is set to one tick.) The shell multiplies this
estimate by 16 and adds 10 ticks to the result to set its maximum time-
out for communications with that server.

The Receive Time-Out is a dynamic time-out that is originally set to four
times the time estimate (received in the Give Local Target response) plus
10 ticks.

Once initially set, the receive time-out adjusts up or down to adapt to
changing network conditions. The receive time-out is increased if the
shell issues a request to a server and does not receive a response within
its current receive time-out. The receive time-out is multiplied by one
and one-half when the first retry to the server is issued. It remains at
this new value for all subsequent retries on the request and for use on
the next request. If the next request requires a retry, the receive time-
out will be increased again. The receive time-out will continue to be
increased in this fashion until it reaches the maximum time-out.

The shell decreases the receive time-out each time that the shell does
not have to issue a retry to a request. To decrease the receive time-
out, the shell takes the time necessary to receive a response to the last
request-the request that didn't require a retry-and multiplies that value
by two and adds 10 Ticks to it. The shell sets the new receive time-out
to the average of this calculated value and the current receive time-
out.

The number of times that the shell will resend a request to a server is
determined by a number called the IPX Retry Count. If this count is
exceeded the shell will give up and present the user with a "Network
error on server xxxxx. Error xxxxx from network. Abort, Retry?" message.
A default for this retry count exists for all drivers. This default
differs from driver to driver but is generally between 20 and 40. The
"IPX RETRY COUNT = xx" option for the SHELL.CFG files allows the default
IPX retry count to be modified; however, some drivers will ignore this
entry in the configuration file and leave the retry count at their
default.

The File Server Connection Table

The file server connection table, shown in part in Fig. 29, allows the
server to keep information about each of the clients that it is
servicing. The address fields are used for addressing response packets
and for security purposes. When a packet arrives with a service request,
it contains the connection number assigned to the sender. The server
matches the packet's IPX source address (network, node, socket) with the
address registered for that connection number. If the addresses don't
match, the server regards the request as a security breach.

: A Portion of the NetWare File Server's Connection Table

The NIC Number and Intermediate Router's Address fields are used for
sending responses to clients. As a request packet is received, the
number of NIC that the request came in on is placed in the NIC Number
field-this number would be A, B, C, or D for NetWare v2.15c and earlier
versions, or the network number of the NIC for NetWare versions 3.0 and
above. If the packet was forwarded through one or more routers, the node
address of the last router is stored in the Intermediate Router's Address
field. Hence, when the request has been processed, the server does not
have to find a route to the client to send a response. The server places
the node address of the first router in the path to the client-from the
Intermediate Routers Address field-in the MAC header destination address
field and sends the packet through the NIC specified in the NIC number
field. Of course, it first places the client's and its own full network
address in the destination and source address fields of IPX header,
respectively.

The Sequence Number field is used for packet-level error checking. The
Watchdog Count and Timer fields are used by the watchdog process, which
is discussed later. File servers also maintain a 100-byte reply buffer
for each of their connections. If a response to a client is less than 100
bytes, the server will make a copy of the response in the buffer that
corresponds to that connection. If the client does not receive the
response and resends the request, the server will not have to reprocess
the request.

Packet-Level Error Checking

The bit-level error checking that network adapters provide detects the
corruption of individual bits within a packet. When an adapter finds that
part of a received packet is corrupted, it discards the entire packet.
Due to the driver's simple design, no mechanism exists within the driver
to request that the packet be resent or to inform the upper-layer
processes and applications that an error occurred. Therefore, the upper-
level sending process (shell or file server) must determine when a packet
has not reached its intended destination.

In the NetWare environment, this packet-level error checking is the
responsibility of the shell. The NCP specifies that a workstation shell
can submit only one request to a server at a time. Furthermore, the
response that the server provides must fit in a single packet-the shell
should never request more than a packet's worth of information. Thus, to
guarantee that no packets have been lost, the shell only has to make sure
that it receives a completed response to each of its requests.

Each request that a shell sends to a server has a sequence number
attached to it within the NCP header. The response that the server
returns is labeled with the same sequence number. Ultimately, the shell
is responsible for getting completed responses for each of the service
requests that it submits. If the shell does not receive a response to its
most recent request within the specified receive time-out, it will
resubmit the request. The shell continues to resubmit the request until
it receives a response or exceeds its IPX Retry count.

Three conditions could cause a shell to time-out while waiting for a
response from a server. Fig. 30 illustrates a case in which the request
is lost in transit to the server. The workstation's timer eventually
expires and the shell resends the same request. The server receives the
second request, processes it, and sends back the response.

: Request Lost in Transit to File Server

In Fig. 31, the request is received by the server but the response is
lost in transit to the workstation. Once the workstation's timer reaches
its limit, the shell sends a second identical request to the server.

When a server receives any request, it checks the request's sequence
number to see that it is one greater than the sequence number registered
in the server's connection table. If it is, the server increments that
number and processes the request as usual. However, if the two numbers
are the same, the server determines that the client, for whatever reason,
is resubmitting its last request. In some cases, the server will have a
copy of the last response. NetWare file servers maintain a 100-byte
response buffer for each of their connections. If the server is sending a
response that is less that 100 bytes in size, the server will make a copy
to that client's buffer-that is, the buffer corresponding to that
client's connection number. Since a large percentage of responses are
less that 100 bytes, a good chance exists that a server will have a copy
of the response when requests are resubmitted by clients. (This type of
response increments the Duplicate Replies Sent counter on the FCONSOLE
Statistics->LAN I/O Statistics screen.) On the other hand, if the request
was larger than 100 bytes, the server must reprocess the request and send
the response. (This type of response increments the Reexecuted Requests
counter in FCONSOLE.)

If the response is still in transit to the workstation when the shell
times out and resubmits the request-that is, the shell receives the
completed response after resending the request-the server will send
another response, but the shell will ignore it.

:  Response Lost in Transit to Shell

Sometimes a server may be too busy to respond within the shell's time-
out. The shell then resends the request. When the server receives this
second request, it sends a reply to the workstation stating that the
initial request was received successfully, but that the processing of it
has not yet been completed (This intermediate response increments the
Positive Acknowledgments Sent counter within the FCONSOLE Statistics->LAN
I/O Statistics screen.) When the shell receives this reply from the
server, it sets its time-out to zero and waits for the request. If the
shell's time-out expires again, it will send a third copy of the request
just in case the response was sent by the server but lost in transit.
This process will continue until the shell finally receives a completed
response. (See Fig. 32.)

: File Server is Busy

Connection-Level Error Checking

The connection between a workstation and server can be lost due to a
power failure or a communications problem. Both file servers and
workstation shells are equipped to handle this eventuality. On the
workstation side, the connection is checked each time a request is made.
If the shell does not receive a response to a request after it retries a
certain number of times (the number dictated by the IPX Retry Count), the
shell assumes that a problem exists with the connection and displays a
message for the user. At this point, the user has the choice of ordering
the shell to resubmit the request again or to abort the operation
completely.

If the operation is aborted the shell removes that connection from its
Connection table. If it does not have any other server connections, it
attempts to create a new connection with a server (using the initial
connection sequence outlined in Fig. 25). If this attempt is
unsuccessful, the shell informs the user with the following message: You
are not connected to any file servers. The shell will try to connect to a
file server whenever the current default drive is changed to an invalid
drive. <Current drive is no longer valid>.

Connection-level error checking at a NetWare file server comes in the
form of address verification and periodic watchdog polling. When a file
server receives a request packet for a certain connection, it verifies
that the IPX source address within the request packet matches the address
recorded for that connection within its connection table. If the
addresses do not match, the server returns a response to the sender of
the request indicating that the connection number and address do not
match.

The Watchdog Process

When a workstation is turned off, regardless of whether the LOGOUT
command was issued, the station's connection remains occupied at the
server. To clear these unused connections, the server uses the watchdog
process to poll (send a query packet to) clients that the server hasn't
heard from for a period of five minutes. This five-minute period is
tracked for each connection in the Watchdog Timer field of the server's
Connection table. If the shell within the station that the server is
polling is still operational, it will respond to the query and the server
will reset its timer for that connection.

However, if the workstation has been turned off or some communications
problem exists on the network, the server will not receive a response
from the shell. In this instance, the watchdog process resets the
connection's Watchdog Timer field to zero, but increments the Watchdog
Counter field by one. The next packet that the watchdog process sends to
the workstation will be sent a minute later. If the watchdog continues to
hear nothing from the workstation, it will send a packet every minute
until it has sent a total of 11 polling packets to that workstation.
Fig. 33 illustrates the timetable for a connection that does not answer
to a server's queries. The server will clear the workstation's connection
if no response to the last watchdog packet is received. (NetWare 386-
based servers provide a setable parameter that allows administrators to
monitor when workstations are logged out by the watchdog process. This
option is set with the following command: SET CONSOLE DISPLAY WATCHDOG
LOGOUTS = ON.)

: Watchdog Timetable for a Connection that Does Not Respond

Conclusions

NetWare's client-server communications are governed by a series of
protocols. These protocols can be broken up by functionality: protocols
used for all communications (the medium access protocols and IPX),
administrative protocols (the RIP and SAP), protocols concerned with
connection control (the NCP and Watchdog) and, finally, the protocol with
defines the coding of service requests (the NCP). This document explains
the operation and interoperation of these protocols; however, it does not
attempt to apply this information to all possible network configurations
and environments. It is up to you to apply this information to your
specific network(s).

Appendix A: Implementing Redundant Cabling

In internetworks that contain 286-based NetWare file servers,
incorporating multiple paths to those file servers may result in
inefficient routing. Fig. 34 shows an example of a 286-based NetWare
internet work that contains redundant paths to two file servers.

: Sample Redundant Path Configuration

The problem with this sample network configuration involves the route
taken by workstations on segment BB to communicate with file server FS1.
Although the shortest route between the workstations on BB and FS1 is
through NIC B on FS1, there is a good chance that packets may pass
through FS2 onto AA and subsequently through NIC A of FS1.

Since traversing through an intermediate NetWare router can cause up to
40 percent degradation in the performance of packet exchanges between a
workstation and a file server, the scenario illustrated in Fig. 35 is not
the most desirable.

: Inefficient Path to FS1

Routing problems occur because of the file service addressing scheme used
for 286-based NetWare file servers, combined with the algorithm for
establishing a connection to a file server.

File Service Addressing

The file services of a NetWare file server are assigned a specific
address within the file server. With 286-based NetWare servers, file
services are addressed with respect to NIC A in the file server. In other
words, when the file server advertises its existence, it provides only
the network and node address assigned to its NIC A-a socket address is
also included but it is not specific to NIC A. a shows a logical
representation of the file service addressing within a 286-based NetWare
file server.

: Addressing of File Services in NetWare File Servers

With NetWare 386, the file services are addressed with respect to an
internal network number assigned when the server is booted up. NetWare
386 assigns the file services node address 1. (See Fig. 36b.)

The Connection Algorithm

The problem inherent to the addressing scheme used for 286-based NetWare
file servers arises when LOGIN, ATTACH or the preferred server shell
attempts to connect to a specific server. Fig. 37 illustrates the way
that the file services of both servers appear to the workstations.

As we have seen, a workstation's Get Local Target request asks for the
fastest route to the network segment on which the file server is located
(segment AA for FS1.)  Since the router in FS1 and the router in FS2 both
register the same distance to network segment AA (two Ticks), both will
respond to the Get Local Target request.

: Logical Positioning of File Services

If FS2 is the first to respond to the requests, the workstation assumes
that FS2 has the fastest route, and therefore sends the create connection
request packet through FS2. If FS2 is consistently faster than FS1 in
responding to Get Local Target requests, connections to FS1 will always
be established through FS2.

Fig. 38 shows the entire sequence that the workstation goes through to
connect to FS1 if FS2 responds to a Get Local Target request first. In
this sequence, FS2 is assumed to be consistently faster than FS1 in
responding to Get Local Target requests.

Since FS2 is always the first to respond, the shell initially connects to
FS2 (using the sequence shown in Fig. 25).  After making this initial
connection, the shell returns the DOS prompt to the user.

: Workstation Sequence For Get Local Target   Figure 38 (Continued):
Workstation Sequence For Get Local Target

The user can then enter the command "LOGIN FS1/" to log in to FS1
(following the sequence outlined in Fig. 27). First, the shell queries
FS2's bindery for FS1's address. Next the workstation broadcasts a Get
Local Target request. The router for FS1 and the router for FS2 both
answer this request, but FS2's router responds first. Therefore, the
workstation assumes that FS2 must have the fastest route to network
segment AA and sends its connection request-and all subsequent packets
intended for FS1-through FS2. Since FS1 depends on the workstation to
find the fastest route between the, FS1 sends all responses through FS2.

To avoid this inefficient routing scenario, you can connect workstations
on the same segment as a file server's NIC A when you have redundant
paths to the server. (See Fig. 39.)  With the correct configuration, the
shell receives the address of FS1 from FS2's bindery and makes the Get
Local Target call to IPX. IPX determines that FS1 and the workstation are
on the same network segment and tells the shell to address packets
directly to FS1.

: Correct Configuration of Redundant Paths with 286-based NetWare

Note that the connection sequence followed for the pre-v3.01 shell and
LOGIN.EXE  is the same as that followed by the preferred server shell.
Therefore, the scenario described above applies for the preferred server
shell when a preferred is specified by the user.

Another Redundant Path Configuration

Fig. 40 shows another possible configuration that incorporates redundant
paths with 286-based NetWare file servers. In this configuration,
workstations on network BB should have direct access to both FS1 and FS2.
Due to the 286-based NetWare addressing scheme, however, packets destined
for one file server might go through the other file server first.

For instance, if a workstation on BB wants to log in to FS1 but initially
connects to FS2, it will query FS2's bindery for FS1's address. The
address returned will include network number AA. The workstation will
then issue a Get Local Target request for AA. If FS2 responds to this
request first, the workstation's communications with FS1 will go through
FS2.

: Redundant Paths With 286-based NetWare File Server

Unfortunately, there is no all-inclusive solution to the routing problems
possible with this configuration. However, the configuration shown in
Fig. 41 will keep unnecessary routing to a minimum. This configuration
places NIC A for server FS1 and NIC A for server FS2 on different
networks: FS1's NIC A is connected to AA; FS2's NIC A is connected to BB.
Furthermore, workstations that access FS1 the majority of the time are
connected to AA, while those that access FS2 most often are connected to
BB. This configuration guarantees workstations a direct path to the file
server that they access most frequently.

: Keeping Routing To A Minimum

Redundant Paths with NetWare 386

Thanks to the internal network addressing scheme used by NetWare 386-
based file servers, they avoid the redundant-path problems experienced by
286-based NetWare servers. To illustrate, suppose FS1 is a NetWare 386
file server with an internal network address of CC. In this case, FS2
registers two Hops to CC, while FS1 registers only one Hop to CC.

When the shell obtains the address CC from FS2's bindery, only FS1
responds to the Get Local Target request. FS2 does not answer the request
because it no longer has a route equal to the fastest route to network
segment CC.

The algorithms the NetWare shell uses to connect to a file server are
relatively simple in design. The basic procedure is the same: get a
server's address, obtain a route to that address, and send a request to
establish a connection with the server.

However, when you configure 286-based NetWare file servers in an
internetwork with redundant paths, the shell may inadvertently route
packets through an intermediate router, even though the workstation is
connected to the same network segment as the file server it wants to
communicate with. As a result, you must carefully design redundant-path
networks to avoid such routing inefficiencies. As a general rule, always
connect those workstations that will spend most of the time accessing a
certain server to the NIC A segment of that server.

Appendix B: Internal Components of a File Server

It is a common misconception that NIC A enjoys a higher priority within
the 286-based NetWare servers and that it is therefore somewhat faster
than the other NICs. However, NIC A must vie for access to routing and
file services as a peer of NICs B, C, and D. In fact, within 286-based
NetWare servers, the only difference between NIC A and its peers is that
the address of the server is tied to it.

286-Based NetWare Communication Components

To fully understand the part that NICs play within 286-based and NetWare
386 servers, it is necessary to look at the communications components
that make up a server. Fig. 42 gives a graphic representation of the
communication-related components of a 286-based server that contains two
NICs.

: Internal Communication Components of a 286-based NetWare File Server

Each NIC has a corresponding driver. These drivers can be logically
separated into a send portion that transmits packets through the NIC and
a receive portion that pulls packets off the NIC. The receive portion is
commonly called the driver interrupt service routine (ISR) since it is
executed each time the NIC generates a hardware interrupt. (In most
cases, a hardware interrupt from the NIC indicates that a packet has been
received.)  When a packet is received, the ISR checks the length of the
packet to make sure that it is large enough to be a viable IPX packet but
not so large that it will not fit into the server's buffers. If the
packet does not pass this test, the driver simply discards it. If the
packet is viable, the driver attempts to place the packet in a buffer.

A 286-based file server uses two sets of packet buffers: file service
process (FSP) buffers and communication buffers. The FSP buffers are
primarily used for processing service requests (NCP packets) and can
number between one and 10, depending on the configuration of the server.
These buffers reside within the DGroup memory segment of the server and
are subject to its limitations. (Due to the design of the Intel 80286
processor, memory must be divided into 64KB segments. The DGroup segment
has been optimized in the NetWare operating system code to be the fastest
segment. It contains several components besides the FSP buffers which,
for larger server configurations, may limit the memory available for
these FSP buffers.)

All FSP buffers are the same size; they are sized to handle the largest
packet that  any of the server's NIC drivers can receive. For instance,
if the server contains an Ethernet driver able to handle 1,024-byte
packets and an Arcnet driver able to handle 512-byte packets, the buffers
will sized to handle 1,024-byte packets.

The communication buffers act as overflow areas for packets being
received by the server. The number of buffers that exist ranges from 40
(the default) to 250 for version 2.15c-this number is set within NETGEN
at installation. These communication buffers are also sized to handle the
largest receivable packet size. Both sets of buffers are set up as first
in, first out queues, or linked lists, where the first packets to be
received are placed at the front of the queue and all subsequent packets
placed in line after that.

Without examining the contents of the received packet, the driver ISR
first attempts to place the packet in an FSP buffer. If the FSP buffers
are full, the ISR will try to place the packet in a communication buffer.
The packet is discarded if both sets of buffers are full. The assumption
is that the packet-level error checking implemented at the transport
layer (handled by the NCP, SPX, and so on.) will cause the sender to send
another packet later when the server is not so busy. Once the ISR has
placed the packet in a buffer or has discarded it, the ISR returns
control of the CPU to the server and waits for another packet to be
received by its NIC. The ISR for each NIC follows this same routine. Each
has equal access to the buffers and places received packets at the end of
the FSP or communication buffer queues.

A routing process services the FSP and communication buffers. (This
process is technically referred to as the Mux process or polling
process.)  The routing process periodically checks the contents of the
FSP and communication buffers. This process is responsible for routing
packets found within these buffers to their proper destination, whether
that be in or outside the server. Generally, five types of packets can be
found in the buffers:

o    Service requests for the file server (NCP packets addressed to the
     server)

o    Packets that need to be routed to another network segment

o    RIP packets

o    SAP packets

o    Packets addressed to other processes internal to the file server,
     such as a nondedicated DOS process or a value-added process (VAP)

When the routing process examines a packet in one of its buffers, it
takes one of four actions:

o    If it finds a service request for the server, the routing process
     will schedule an FSP to service the request. The routing process
     will then go on to the next buffer.

o    If it finds a packet not addressed to the server, the routing
     process will check its Routing Information table for the best route
     to the destination and send the packet through the appropriate NIC.
     In this capacity, the routing process acts as the internal router of
     a file server.

o    If it finds a RIP or SAP packet the routing process will update its
     Routing or Server Information table, respectively, if necessary.
     However, if the packet is a RIP or SAP request (such as a Get
     Nearest Server request) the routing process will get the appropriate
     information from its tables and send a response.

o    If it finds a packet addressed to another process within the server
     (the packet would be identified by the destination socket number in
     the IPX header) the routing process will pass the packet on to that
     process.

The routing process first checks the FSP buffers, starting at the top of
the queue. Since file service requests to the server can only be
processed in the FSP buffers, the routing process must try to keep the
FSP buffers as free as possible for these types of packets. Since the NIC
driver ISRs indiscriminately place packets into whichever buffers are
free at the time, the routing process may have to shuffle packets back
and forth between the FSP and communication buffers. Before checking the
contents of the FSP buffers, the routing process checks into see if all
the buffers are full. If so, the routing process assumes that some NCP
requests may have overflowed to the communication buffers. Therefore, any
non-NCP packets that the routing process finds in the FSP buffers are
moved over to the communication buffers to make room in the FSP buffers
for all the NCP requests. If the FSP buffers are not full, the routing
process simply processes all of the packets where they are.

Having completed the scheduling or movement of packets in the FSP
buffers, the routing process switches its attention to the communication
buffers. The routing process attempts to move any NCP request packets
that it finds over to the FSP buffers. It places these packets in a
separate queue within the communication buffers if the FSP buffers are
full. This queue is later checked by the FSP buffers as they finish
processing their current requests. Any packets that are not NCP requests
are routed or processed within the communication buffers by the routing
process.

NetWare 386

The NetWare 386 servers follow the same communication mode as 286-based
servers, with the following exceptions:

o    NIC drivers may be used re-entrantly to handle one or more NICs,
     therefore saving RAM.

o    Only one set of packet buffers exists within a NetWare 386 server
     (this difference stems from the 32-bit addressing scheme used by 386
     processors.)

o    FSP buffers are taken from a pool as they are needed and are not
     assigned to one specific buffer. The number of FSP buffers may
     increase as the load on the server increases.

o    NetWare 386 servers contain an internal network number for server
     addressing.

Fig. 43 illustrates the structure of the NetWare 386 communications
environment.

: Internal Communication Components of a NetWare 386 File Server

Appendix C: RIP and SAP Bandwidth Requirements

On large internetworks with several hundred servers, administrators
become concerned with the load that RIP and SAP broadcasts will place on
their network segments. Of course, these concerns can be appeased for
asynchronous and X.25 links since only changed server and routing
information is sent on these lines. On other segment types the traffic
caused by these broadcasts does not cause a sginificant load. The
requirements and some examples are shown in Fig. 44. As you can see, the
SAP broadcasts for an internetwork containing 250 servers account for
less than one percent of the total bandwidth (10Mb/s) of an Ethernet
segment.

: Bandwidth Requirements for 60 Second Broadcasts

Total traffic load of routing and server information broadcasts on any
given segment will be equal to broadcasting information about all the
network segments and servers that exist on the internetwork. For example,
on a T1 link between two NetWare routers, one router will broadcast
information about all of the network segments and servers that it is
making available to the other router (using the best information
algorithm). The other router will broadcast information about all the
segments and servers that it is making available to the first router. The
total of the two equals the total number of servers and segments that
reside on the internetwork.